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7 Implementing IBM's Language Environment: Part I 

By Craig Collins and Dave Christianson 

As the 20th century comes to an end, time is running out for the COBOL, 
PL/I, C, and FORTRAN run times. Now is the time to convert your current 
run-time to Language Environment (LE). 

12 Remote Access for a P/390 OS/390 System: Part I — Research and Evaluation 

By Rex Widmer 

This article describes various remote connectivity options to provide remote 
access for MVS running on the P/390 platform. 


20 Vendor Performance Ratings: Why Your Results May Differ — Part I 

By Cheryl Watson 

This article, the first in a four-part series, provides an explanation of why your 
performance may or may not match the vendor’s performance results. It also 
provides some suggestions on how to confirm the performance you receive. 

26 Common Mistakes in Business Resumption Planning: 

Part III — Avoiding Deadly Mistakes 

By Leo A. Wrob el 

To create a successful business resumption plan, it is first necessary to determine 
who in the organization does it, how, and with what tools. This knowledge can 
help your company avoid deadly mistakes. 
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31 Frame Types: Sorting Out the Confusion 

By Mark Bell 

Frame type problems only surface when you are using IPX and NetWare servers. 
All other protocols set the frame type by default; this process being transparent 
to the users. 
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S/2 INSIGHTS 


Java for OS/2 

BY MIKE NORTON 


L ast month, I noted how the OS/2 
Workplace Shell is losing its relevance 
as browsers increasingly usurp the role 
of user interfaces traditionally held by 
operating systems. The migration is sure to 
be tumultuous. Microsoft’s recent legal 
problems with the Justice Department and 
Sun Microsystems are indications of tech¬ 
nological growing pains as a fundamental 
paradigm shift occurs. This phenomena 
reminds me of the first time 1 saw windows 
— on an Apple Macintosh — and recognized 
that the DOS world I had grown accus¬ 
tomed to would soon be swallowed up by 
this new, exotic method of interfacing with 
a computer. The more things change, the 
more they stay the same. 

While Microsoft understandably works 
to undermine the impact of Java, IBM has 
embraced it. It is difficult to read a com¬ 
puter journal without encountering an 
article describing how intertwined IBM and 
Java are becoming. Certainly talking to 
IBM officials leaves one with an impres¬ 
sion of just how strategically important 
Java is to IBM. Although it went largely 
unnoticed, beginning with Version 4.0, 
OS/2 ships with a specialized version of the 
JDK (Java Development Kit) 1.0.1 from 
Sun Microsystems. 

WHAT IS JAVA? 

At first glance, this seems to be an obvious 
question, considering the enormous amount 
of publicity that Java has received; however, 
I’ve worked in technical support too long 
to take anything that simple for granted. 
Besides, I’ve encountered too many mis¬ 
conceptions about Java to simply assume 
that everyone is on the same page. 

Java’s convoluted evolution from a 
language for toasters to being the toast of 
the ’net and a burr in Bill Gate’s saddle has 


in no small part contributed to the miscon¬ 
ceptions. Although most people know Java 
as a means of animating web pages, that is 
incidental. Java was originally intended to 
be an operating system of sorts for “smart” 
machines, such as those inane talking Coke 
machines that gratefully died a quick death. 
The Java run-time environment is a virtual 
machine that executes on top of the operating 
system, analogously to Windows in OS/2. 
Fully functional applications, which look 
and feel like applications native to the oper¬ 
ating system, may be developed using the 
Java language. Java source code — plain 
ASCII text, that looks (and is) very similar to 
C++ — is compiled into pseudo-code 
and is then loaded into the virtual machine. 
The virtual machine then translates this 
pseudo-code into native operating system 
code at execution. 


The Java run-time environment 
is a virtual machine that executes 
on top of the operating system, 
analogously to Windows in OS/2. 


It is this run-time environment that 
Web browsers emulate to run special Java 
programs called applets. The virtual 
machine is also what allows a Java program 
to be “compiled once, run anywhere.” The 
pseudo-code is operating system-independent; 
the same code runs on Windows, OS/2 and 
UNIX. Thus, each operating system has a 
unique virtual machine that translates the 
pseudo-code on the fly. For this reason it is 
sometimes said that Java is a compiled and 
interpreted language. Obviously, there is a 


performance issue with the interpretive 
aspect of the process, a problem addressed 
by JIT (Just-In-Time) Java compilers that 
optimize the interpretive process. 

Everything you need to develop Java 
applets is contained in the Java for OS/2 
Development package, including the virtual 
machine, the compiler, an applet viewer that 
lets you run an applet outside of a browser 
(trust me, you'll want to), debug and other 
development utilities. While there are those 
who prefer visual design tools such as IBM's 
Visual Age for Java, inveterate command- 
liners like me will find this package con¬ 
tains everything we need. 

INSTALLING JAVA 

Java for OS/2 is not installed by default. 
Assuming OS/2 is already installed, to 
install the Java Development tools for 
OS/2, open the “System Setup” folder, 
select “Install/Remove,” then double-click 
on the “Selective Install” icon. Don’t select 
anything from the first two panels displayed, 
just click the “Next” button. The third panel 
presents a number of options, including 
“Java Development.” Select the checkbox, 
then click “Next.” Note that you can only 
select the drive on which to install the Java 
support files; neither the directory name, 
“JAVAOS2,” nor its location immediately 
off the root drive are optional, at least not 
during installation. (If some soul with 
enough time on his hands cares to move the 
JAVAOS2 directory and update the appro¬ 
priate statements in the CONFIG.SYS, 
please let me know if it works.) There are 
some further considerations if Netscape 
Navigator is installed on your system or if 
you’re planning to install Navigator. 
Netscape provides Java support at the 1.02 
level and will replace some of the JAVAOS2 
files, although I haven’t noticed any effect 
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from either the development or the run-time 
side of things. To ensure that the proper 
files are updated, reinstall Navigator after 
installing OS/2 Java support. 

PL^G WITH THE SAMPLE APPLETS 

If you’ve installed Java support correctly, 
you will be greeted with “Java for OS/2,” 
which is a new folder in your “Programs” 
folder on your Desktop. Open the enclosed 
“Samples for Sun’s Java Programming 
Environment” folder and then the “URLs for 
Samples” folder. Double-click on any of the 
icons to launch one of the dozens of sample 
programs provided. From graphics to anima¬ 
tions to spreadsheets, you'll find the rudi¬ 
mentary Java techniques well represented; 
my personal favorite is the “Bouncing Heads,” 
although probably not for the right reasons. 
True to Blue form. IBM has not skimped on 
sample code — and it actually works! 
Although Eve surfed a web site or two, and 
pored over more than one Java tome. I’ve 
yet to find a collection for the beginning 
Java student that is better (and certainly 
more fun) than the OS/2 Java samples. 


HELLO WORLD. AGAIN 

Indeed, Java is the first language I’ve used 
in which a “Hello World” example extracted 
straight from the book failed to compile! 
Next month, using the tools available in the 
OS/2 Java Development package, I’ll write 
a “Hello World” program that does work. In 
the meantime, install the package, play with 
the applets, and realize you’re looking at 
the future as IBM envisions it. E 

Was this column of value to you? If so, 
please circle Reader Response Card No. 43. 



Michael Norton is the work¬ 
station division manager 
at SofTouch Systems. 
Oklahoma City. Okla.. which 
provides both mainframe 
and PC software solutions. 
He has written mainframe manuals in addition to articles 
for a number of publications. Michael can be contacted 
at mnorton@softouch.com. 
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Continued from page 54. 

8. Naming standards for printers: 

When we first started implementing 
network-attached printers, we simply 
named them HPLAS001, HPLAS002, 
HPLAS003, etc. This was fine when 
we had less than 10 printers. Now that 
we are up to HPLAS235 we have 
a problem. When a user calls with 
a printing problem, we have no idea 
where the printer is and who uses it. 
We have since developed a new printer¬ 
naming standard and are in the process 
of converting all of the old names 
to the new convention. 

9. Use network-attached printers: 

When we first rolled out the network, 

I decided to rely on the Novell 
NPRINTER utility to provide network 
printing rather than directly connecting 
the printers to the network via 
a JetDirect card or NetPort. The 
NPRINTER utility requires that the 
user’s PC that controls the printer 
be up at all times. When the user shuts 
down his system, the network printer 


is no longer accessible, resulting 
in a help desk call. Hard wiring the 
printers will reduce the number 
of support calls in your organization. 

10. Implement Win95 policies: When 
we first rolled out Windows 95 to 
our users, we were deluged with help 
desk calls resulting from end users 
modifying the Win95 settings or 
implementing their own software. 

The Win95 policies allow you to 
restrict the users access to certain 
areas within Windows 95, such as 
the Control Panel. We have since 
implemented the Windows 95 policies 
and our help desk call volume has 
been reduced accordingly. 

CONCLUSION 

Well, I really feel humbled after telling 
you all of my failures, but, believe it or not, 
I did make some good decisions along the 
way. Perhaps I will share my good decisions 
in a future column. If you have any questions, 
comments or future ideas for this column, 
feel free to contact me at johnj@fast.net. 

E 


Was this column of value to you? If so, 
please circle Reader Response Card No. 42. 



NaSPA memberJohn £ Johnston is manager 
of technical support and communications for 
a major hospital in Pennsylvania. He designs and 
maintains cross-platform local and wide area 
networks utilizing NetWare. OS/2. DOS and Windows. 
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